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Summary 

A cognitive engineering analysis of the 
Flight Management System (FMS) Vertical 
Navigation (VNAV) function has identified 
overloading of the VNAV button and 
overloading of the Flight Mode Annunciator 
(FMA) used by the VNAV function. These 
two types of overloading, resulting in modal 
input devices and ambiguous feedback, are 
well known sources of operator confusion, 
and explain, in part, the operational issues 
experienced by airline pilots using VNAV in 
descent and approach. A proposal to modify 
the existing VNAV design to eliminate the 
overloading is discussed. The proposed 
design improves pilot’s situational 
awareness of the VNAV function, and 
potentially reduces the cost of software 
development and improves safety. 

Introduction 

Each new generation of aircraft has 
increasing levels of flight deck automation 
that have improved the safety and efficiency 
of airline operations (ref. 1). The full 
potential of these technologies has not been 
fully realized however. A case in point is the 
potential to improve operations during the 
workload-intensive descent and approach 
phases of flight (ref. 2). The Vertical 
Navigation (VNAV) function of the Flight 
Management System (FMS) serves as an 
intelligent agent during these phases by 
automatically selecting appropriate targets 
(e.g. altitude, speed, and vertical speed) and 
pitch/thrust control modes to satisfy the 
objectives of each leg of the flightplan. This 
decision-making logic is complex (refs. 3, 4) 
and has raised several sets of human factors 
related concerns (refs. 2, and 5-7). 

The VNAV function (also known as the 
PROF function) accounts for the majority of 
reported human factor issues with cockpit 
automation. Vakil & Hansman’s (ref. 8) 
review of Aviation Safety Reporting System 
(ASRS) reports, an anonymous incident 


reporting data-base for pilots, found that 
63% of pilot-cockpit interaction issues were 
in the control of the coupled vertical/speed 
trajectory of the aircraft performed by the 
VNAV function. The Australian Transport 
and Regional Development Department’s 
Bureau of Air Safety Investigation (ref. 2) 
reported that a survey of pilots identified the 
VNAV function as ‘"the most disliked 
feature of automated cockpit systems.” 

Many of the issues with the use of VNAV 
are related to the incompatibility between 
the tactical Air Traffic Control (ATC) 
operations and the strategic FMS flightplan 
(refs. 2, 4). Difficulties that pilots have in 
communicating ATC instructions to the 
FMS, via the heads-down Multi-function 
Control and Display Units (MCDU), and 
poor feedback to the pilot have also been 
cited (refs. 9-11). Researchers at Boeing, 
Honeywell, NASA and airline partners are 
actively working to address these issues 
(refs. 10, and 12-15). 

This paper describes an additional issue with 
the operation of the VNAV function that 
contributes to the pilots’ ability to 
understand what the VNAV function is 
doing, why it is doing that, and what it is 
going to do next (ref. 16). A cognitive 
engineering analysis of the NASA Research 
VNAV function (representative of the PROF 
function on Airbus aircraft and the VNAV 
functions in modem Boeing airplanes) 
identified that the current design of the user- 
interface for the VNAV function violates 
two basic principles of cognitive 
engineering for interfaces between operators 
and complex automation: 

1 . The VNAV button is overloaded in 
descent and approach phases of flight. 
Selecting the VNAV button results in 
the engagement one of six possible 
VNAV commanded trajectories. 
Furthermore, the VNAV commanded 
trajectories will change autonomously as 



the situation evolves. The automation 
human factors literature (e.g., ref. 17) 
characterizes such buttons as “moded” 
(or “modal”) input devices, and the 
behavior of the VNAV function as 
“autonomous” (e.g. ref. 1 8). 

2. Flight Mode Annunciator (FMA) for the 
VNAV function is overloaded in 
descent and approach phases of flight 
The same FMA is used to represent 
different trajectories commanded by the 
VNAV function. The literature (e.g., ref. 
3) describes such problems as 
incomplete feedback from the 
automation to the operator of 
automation behaviors, goals, and 
internal states of the perceived situation. 

Overloading of user-interface input devices 
and overloading of display feedback are 
well known sources of operator confusion 
(ref. 19). These principles are considered to 
contribute directly to the difficulties pilots 
have in learning, understanding, and 
predicting complex automation behavior. A 
team of Boeing, Honeywell, NASA and 
airline partners are actively working to 
address this issue. This paper summarizes 
this research to date. 

Organization of the Report 

The next section summarizes the literature 
on issues using the VNAV function in a 
modem aircraft. This is followed by sections 
that describe the cognitive engineering 
principles used in this 


analysis, the analysis of the NASA Research 
VNAV function, and improvements to the 
current design of the VNAV function user- 
interface to satisfy the cognitive engineering 
design principles. These proposals are 
currently under investigation by Boeing, 
Honeywell, and NASA engineers and 
researchers. Conclusions and future work 
are described in the final section. For the 
purpose of this paper, we shall refer to the 
PROF function, found on Airbus and some 
McDonnell Douglas aircraft, as the “VNAV 
function” as is common practice industry 
(e.g. VNAV approaches). 

Issues with VNAV Operation 

Pilots generally use the VNAV function 
during the climb and cruise phases of flight. 
In a survey of 203 pilots at a major U.S. 
airline, McCrobie et al., (ref. 20) found that 
73% of pilots used VNAV in climb phase, 
while only 20% used the function in descent 
and 5% use the function in approach. 

The low levels of use of the VNAV function 
are primarily a result of the incompatibility 
between the tactical operation of ATC and 
the strategic behavior of the FMS. BASI 
identified that complying with difficult air 
traffic control instructions in descents and 
approach was the most common reason for 
pilot workarounds of the automation (ref. 2). 
Industiy, the FAA, and NASA are jointly 
working to create ATC procedures with 
greater strategic planning capability (e.g. ref. 

21) and developing decision-aiding tools for 
ATC controllers that optimize aircraft flow 
and minimize ATC tactical vectoring (ref. 

22 ) . 
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Table 1 . Sample of issues with VNAV function reported in a survey of 203 pilot at major U.S. 
Airline (ref. 20). 



VNAV function Issue 

Percentage Pilots Reporting Surprising 
VNAV Behavior 
(Occasionally/Usually/ Always) 

Deceleration too early 

78% 

Unexplained altitude errors 

58% 

Unpredictable speed targets during approach 

56% 

Unpredictable speed targets during descent 

47% 

Failure to make altitude restrictions 

43% 

Deceleration too late 

15% 

Airplane starts down to early 

14% 



When the ATC environment allowed pilots 
to use the VNAV function, sixty one percent 
of the pilots surveyed by BA SI agreed that 
there were things about the automation that 
took them by surprise (ref. 2). For example, 
when the VNAV function is used in descent 
and approach, pilots reported that the 
function does not perform the task as they 
had expected (Table 1). 

The perceived complexity of the VNAV 
function has resulted in airline operators 
training only the basic features to operate 
the VNAV function (refs. 11, 23). The 
airlines are effectively relying on the pilot 
community to discover and informally 
communicate to each other ways of using 
the function in all flight regimes. This is 
reflected in a series of surveys that found 
that pilots request additional training on 
VNAV and other FMS functions over all 
other aircraft systems (refs. 2, 4, 20). 

User’s Perspective of Issues with the 
VNAV Function 

The VNAV function provides three 
automated features: 


1 . VNA V automatically selects altitude 
targets and speed targets according to 
pilot MCP entries and the altitude and 
speed constraints in the FMS flightplan. 

2. VNA V automatically selects pitch and 
thrust control modes to fly to the targets. 
For example during descent, VNAV 
chooses between a FLCH descent, a 
vertical speed (fixed rate-of descent), 
and an FMS path descent. In the case 
where VNAV selects vertical speed 
control mode, VNAV also selects the 
vertical speed target. 

3. For the descent and approach, VNA V 
automatically provides an optimum path 
that is used as the reference for all 
automated altitude/speed target and 
control mode selections. 

Automated selection of VNA V targets 

In a study of the software of contemporary 
VNAV functions. Sherry & Poison (ref. 3), 
found that the typical VNAV function 
automatically chooses the active altitude 
target from a possible list of sixteen, and 
chooses the active speed target from a 
possible list of twenty-six. Pilots are 
generally familiar with only a small set of 


3 










these targets that occur most frequently and 
are self-explanatory. 

For example, the VNAV altitude target is 
almost always the pilot entered MCP 
altitude. In rare cases, when the MCP 
altitude has been raised above a constraint 
altitude in the climb phase of the FMS 
flightplan (or lowered below a constraint 
altitude in the descent phase of the FMS 
flightplan), the VNAV function will capture 
and maintain the constraint altitude (and not 
the MCP Altitude). Hutchins (ref. 1 1) 
describes scenarios in which pilots became 
confused with the relationship between the 
MCP altitude and the FMS flightplan 
altitude. 

The remaining altitude targets automatically 
selected by VNAV cover “comer cases” and 
are rarely observed during revenue service 
operations. For example, the VNAV 
function will automatically level the aircraft 
off if there is a conflict between the 
direction of the pilot entered MCP altitude 
and the phase of the flightplan. Dialing the 
MCP altitude below the aircraft in the climb 
phase of the flightplan results in an 
immediate level off. Other unusual altitude 
targets include; an intermediate level-off at 
1 0,000 feet during descent to bleed off 
speed to satisfy the 10,000ft/250kt. 
restriction, an intermediate level-off to 
intercept the glideslope, or when the aircraft 
has descended below the Minimum Descent 
Altitude (MDA) on a non-precision 
approach. 

There are three keys to demystifying VNAV 
selection of targets. First a deep 
understanding of the FMS flightplan and 
how the altitude and speed constraints are 
used to determine targets is required. This 
must be coupled with knowledge of the 
dynamic relationship between the MCP and 
the FMS flightplan for selecting targets (ref. 
11). Finally, the “comer case” targets of the 
VNAV function must be understood (ref. 3). 


Automated selection of VNA V pitch/thrust 
control modes 

Automated mode selection by the VNAV 
function of pitch/thrust control modes can 
be confusing in two ways. The most 
common source of confusion is the 
autonomous transition of the mode without 
pilot action (refs. 16, 18, and 24-26). These 
“silent” mode transitions are made when 
VNAV detects that certain criteria have been 
satisfied. For example, when the aircraft 
speed exceeds a threshold (typically 20 
knots) above the FMS path speed, VNAV 
will autonomously switch control modes 
from VNAV-PATH to VNAV SPEED (ref. 
2). These thresholds are generally not 
annunciated on cockpit displays. 

The second source of confusion is the 
selection of control modes made by VNAV 
given the circumstances of the aircraft. For 
example, several pilots prefer to perform 
descents to crossing restrictions with a fixed 
rate of descent (i.e. vertical speed mode). By 
triangulating time (or distance) to the 
waypoint and remaining altitude, pilots can 
ensure making the restriction. In certain 
circumstances VNAV will choose speed-on- 
pitch with idle thrust and request airbrakes 
to make the restriction (ref. 3). 

The key to understanding the choice of 
control modes made by the VNAV function 
is to understand the overall FMS philosophy 
on how descents are flown. Researchers 
have also proposed annunciating the 
intentions of VNAV (refs. 3, 27). 

Automatic use of FMS optimum path as a 
reference 

One of the biggest contributors to pilot 
confusion with VNAV is the FMS computed 
optimum path. The path, computed by the 
FMS using models of aircraft performance, 
takes into account the regulations and 
constraints of standard arrival procedures 
(STARs) and published approaches. The 
nuances of the path, such as how far way 
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from waypoints decelerations are initiated, 
are non-intuitive, and worse, not displayed 
in the cockpit. 

Compounding the complexities of the path is 
the issue of control. When the aircraft is 
capturing and maintaining the path, the 
aircraft altitude control is earth-referenced 
with the goal of placing the aircraft 50-ft 
above the runway threshold. This operates 
much like the glideslope, except that the 
reference beam is provided by the FMS, not 
a ground-based transmitter. Unlike other up- 
and-way control modes, the aircraft will 
maintain the path without drift in the 
presence of wind. 

When the FMS optimum path is not 
constrained by crossing restrictions and 
appropriate wind entries have been made, 
the aircraft will descend at the desired speed 
with the throttles at idle. When the path is 
constrained or wind entries are sufficiently 
inaccurate, speed must be maintained using 
throttles (for underspeed) and airbrakes (for 
overspeed). 

This “earth-referenced” control of altitude 
has been observed to confuse pilots who, on 
request from ATC to expedite the descent, 
add thrust or extend airbrakes. Because 
VNAV is controlling to the path, these 
actions simply increase or decrease speed 
without any effect on aircraft rate-of- 
descent. 

The key to understanding the VNAV 
behavior in descent is to have full 
knowledge of the FMS optimum path. 
Several Vertical Situation Displays (VSDs) 
have been proposed to remedy this situation 
(refs. 1 1-15). Also, pilots must understand 
the differences between airmass-referenced 
descents, such as FLCH, and earth- 
referenced descents on the path. 

VNAV User-Interface 

The pilots user-interface provides little 
information on the automatic selections of 


the VNAV function described above. Pilots 
engage the VNAV function through an 
action (button push or knob pull/push) on 
the MCP. In some aircraft the button is 
backlit indicating that the VNAV function is 
engaged. 

Pilots primarily monitor the behavior of the 
VNAV function by monitoring the trajectory 
of the aircraft (ref. 28). Under the 
assumption that the aircraft control surfaces 
and stability augmentation functions are 
operating normally, aircraft altitude, aircraft 
vertical speed, aircraft pitch, and the 
position of the throttle levers (or indicated 
thrust) are used to infer what VNAV is 
doing. Pilots are “surprised” by the behavior 
of the VNAV function when the aircraft 
trajectory or the thrust indicators do not 
match their expectations. For example, when 
the aircraft vertical speed fails to decrease as 
the aircraft approaches an assigned altitude, 
pilots wonder whether the VNAV function 
is commanding a capture to the altitude. 

Secondary sources of information on VNAV 
include the Flight Mode Annunciator 
(FMA), targets on the Primary Flight 
Display (PFD) altitude tape and speed tape, 
and various MCDU pages (e.g. RTE/LEGS 
(or F-PLN), PROG page, CLB/CRZ/DES 
pages). None of these sources explicitly 
identify the source of targets or rationale for 
control modes, pilots are required to 
interpret this information to draw 
conclusions on VNAV behavior to explain 
discrepancies in aircraft trajectory or thrust 
setting. In frequently occurring normal 
operation, these inferences can be made 
easily. In non-frequent or comer-case 
situations, making this kind of inference 
requires a deep understanding of the VNAV 
function and it’s rules of behavior. 

Summary 

The de facto philosophy in developing 
cockpit automation is to use automation to 
build intelligent agents that automate 
operator tasks. This philosophy recreates a 
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number of already difficult problems with 
communication and intent inferencing 
between agents. An alternative philosophy is 
to use the computing power to create 
environments in which the operators get to 
be smart while using cognitive processes. 
This is the spirit of the guidelines developed 
by Billings (ref. 29) for human-centered 
automation: 

“To command effectively, the human 
operator must be involved and informed. 
Automated systems need to be predictable 
and capable of being monitored by human 
operators. Each element of the [cockpit] 
system must have knowledge of the other’s 
intent.” 

This paper examines the efficacy of the 
input devices and the display feedback 
devices of the VNAV function for creating 
an environment in which the pilot is 
“involved” and “informed.” The analysis 
examines how “smart” the automation 
makes the pilot look, rather than how 
“smart” the automation is. The next section 
describes cognitive engineering and the 
method for analysis of user-interfaces. This 
is followed by a cognitive engineering 
analysis of the NASA Research VNAV 
function. Based on the cognitive engineering 
design principles, options for new user- 
interfaces for the VNAV function are 
proposed. 

Cognitive Engineering Design 
Principles 

Cognitive engineering is an engineering 
discipline conceived to provide a scientific 
approach to the design of interfaces between 
complex automated systems and their 


operators (ref. 19). Cognitive engineering 
specifically provides guidance for the design 
of automation and it’s user-interface to 
account for the performance characteristics 
and limitations of the human operator. 

Cognition and Automation 

Human-computer interaction can be 
represented by a model of two-way 
communication between the operator and 
the automation (ref. 29). The operator 
communicates their intentions to the 
automation using input devices provided on 
the automation user-interface (Figure 1). 

The automation acknowledges operator 
instructions and provides feedback of its 
behavior over time to the operator via the 
user-interface. 

Norman (ref. 19) proposed that operators of 
automated systems form “mental models” of 
the way the system behaves and use these 
models to guide their interaction with the 
system. This interaction with the automation 
(and much other human behavior) can be 
thought of as a continuous process of cyclic 
interaction (ref. 30). In the case of a pilot, to 
achieve a trajectory goal, the pilot performs 
a set of actions that lead to changes in the 
automation. These, in turn, cause changes in 
the environment. Evaluation of the state of 
the environment leads to reformulation of 
the pilot’s goals and further action, leading 
to a new state of the environment, and so on. 
This model of cyclic interaction is at the root 
of most modem models of cognition, for 
example; Card, Moran, & Newell’s (ref. 31) 
recognize-act cycle, Norman’s (ref. 19) 
seven stage cycle, and Anderson’s (ref. 32) 
ACT-R model. 
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Figure 1.(1) Situation, (2) goal, and (3) action sequence of pilot interaction with automation. 
Boxes represent knowledge required by the pilot. 


This cyclic interaction is abstracted in the 
pictogram illustrating a pilot’s interaction 
with the cockpit automation (Figure 1). 
Based on information from the environment, 
the pilot formulates a definition of the 
perceived situation (box 1). In the 
aviation human factors literature, 
building and maintaining a 
representation of the situation is known 
as “situation awareness” (refs. 33, 34). 
The perceived situation is used to 
determine appropriate goals (box 2). The 
goals are mapped to a sequence of pilot 
actions on the MCP (box 3). In many 
cases, the sequence of pilot actions on 
the MCP leads to the formulation of sub- 
goals and sub-actions as described in 
hierarchical task models such as GOMS 
(ref. 35) and OFM (ref. 36). 

Breakdowns in Pilot-Automation 
Communication 

Each of the cognitive activities (box 1 , 2, & 
3) must be trained and maintained. As is the 
case for all cognition, when these mental 
processes are complex, time-consuming, or 
brittle, they are subject to failure. 


Breakdowns in communication between 
operator and automation occur when: 

The design of the task and the design of 
input devices require complex, time- 
consuming, and/or error-prone mental 
processes to formulate sequences of 
operator actions. As a result, the pilot’s 
intentions for the behavior of the 
automation are not always accurately 
conveyed to the automation. 

The design of the task and the feedback 
devices require complex, time- 
consuming, and/or error-prone mental 
processes to infer the behavior 
commanded by the automation. As a 
result, the pilot misunderstands the 
behavior commanded by the automation. 

These failures may be due to the absence of 
appropriate knowledge in the pilot’s head 
(box 1, 2 or 3), or when the knowledge is 
present, a failure in cognition (refs. 19, 37). 

Cognitive engineering principles define 
characteristics for user-interfaces that 
eliminate the need for pilots to hold large 


7 






sets of knowledge. They provide visual cues 
to help the pilot remember action sequences 
(e.g. prompts and labels) and identify tasks 
performed by the automation. 

Minimizing Operator Miscues by 
Design of the User-interface 

There are two basic principles of cognitive 
engineering that minimize the rules that 
must be memorized to operate the 
automation. These principles provide for 
more robust operator performance and 
reduced training requirements. 

Cognitive Engineering Design Principle: 
One Input Device — One Automation 
Behavior 

One of the biggest contributors to the need 
for a pilot to memorize sequences of actions 
are user-interfaces with buttons, or other 
input devices, that invoke different 
automation behaviors depending on the 
situation. 

Based on an analysis of pilot tasks, the 
cognitive engineering design principle, One 
Input Device - One Automation Behavior, 
creates one clearly labeled input device for 
each pilot-commanded behavior of the 
automation. In this way the pilot should be 
able to translate an ATC instruction, or some 
other pilot goal, directly into an action on 
the appropriate input device. For example, 
the ATC instruction to “turn left heading 
two-seven-zero,” results in the pilot dialing 
the MCP heading knob left to 270 degrees 
and pushing a heading button (Note: MCP 
actions may vary by aircraft type). This task 
is always conveyed to the autopilot using 
this knob/button. This is the only function 
provided by this knob/button. 

A class of pilot errors has been attributed to 
overloaded (or modal) input devices (ref. 

1 9). These input devices invoke different 
automation-commanded behaviors 
depending on the situation when they are 
selected (refs. 13, 38). For example, the 
MCP vertical speed wheel on a NASA 


Research Autopilot was demonstrated to be 
a source of pilot errors (ref. 39). This input 
device resulted in two different autopilot 
behaviors depending on the situation when it 
was selected. Selecting the vertical speed 
wheel: 

1 . when the aircraft was outside the 
capture region, commanded the aircraft 
to fly to the assigned altitude (and armed 
the capture) 

2. when the aircraft was inside the capture 
region, commanded the aircraft to fly 
away from the assigned altitude (and 
disarmed the capture) 

Frequently pilots were unaware of the dual 
nature of the vertical speed wheel, or could 
not distinguish between the dual “modes” of 
the wheel. As a result pilots were surprised 
by the behavior commanded by the 
autopilot. See also Palmer (ref. 25), Degani 
& Heymann (ref. 38), and NTSB (ref. 40). 

This phenomenon is compounded by 
automation with decision-making logic that 
autonomously changes the mode selected by 
the pilot based on the situation perceived by 
the automation (ref. 29). Sarter & Woods 
(ref. 1 8) use the phrase “strong and silent” to 
characterize this phenomenon. The 
automation is “strong” in the sense that it 
has a lot of authority to determine the 
aircraft trajectory. It is “silent” in the sense 
that the change in commanded behavior is 
made autonomously by the automation and 
is not always revealed by the user-interface 
to the pilot. 

Cognitive Engineering Design Principle: 
One Automation Behavior - One Display 
Configuration 

User-interfaces with display configurations 
that represent more than one automation 
behavior require the operator to memorize 
cues from several displays to infer the 
behavior commanded by the automation. 

The cognitive engineering design principle, 
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One Automation Behavior - One Display 
Configuration, eliminates the need to 
memorize display inference rules by 
creating one unique display configuration 
for each unique behavior commanded by the 
automation. 

The FMA on the Primary Flight Display 
(PFD) provides an explicit mechanism to 
distinguish between the different automation 
commanded behaviors. For example, the 
NASA Research Autopilot FMA (ref. 41) 
annunciates the aircraft mechanisms to 
control speed and altitude (<SPEED control 
mechanism> || <ALTIUDE control 
mechanism>). The annunciation of PITCH || 
CLB THRUST provides the pilot feedback 
that aircraft pitch is being controlled to 
maintain the selected speed, and that the 
aircraft is climbing to the assigned altitude 
with maximum thrust. (Note: the FMA on 
other aircraft display the parameter 
controlled by the thrust axis and the 
parameter controlled by the pitch axis 
instead.) 

A class of pilot errors has been attributed to 
feedback devices that fail to distinguish 
between two different behaviors. For 
example, the FMA on the NASA Research 
Autopilot (ref. 41) was demonstrated to be a 
source of pilot error due to the use of the 
same annunciation THRUST || VS for 
autopilot commands for: 

1 . a climb/descent to capture and 
maintain the assigned altitude 


2. a climb/descent away from the 
assigned altitude 

3. a special case of speed protection 

Frequently pilots, unaware of the other 
interpretations of the THRUST || VS 
FMA, assumed the aircraft was going to 
capture and maintain the assigned 
altitude. When the autopilot commands 
drove the aircraft through the assigned 
altitude, they were surprised. See also 
NTSB (ref. 40). 

Cognitive Engineering Analysis 
of the VNAV Function 

The NASA Research VNAV function, 
representative of a modem air transport 
VNAV function, was analyzed for 
compliance with the two cognitive 
principles described above. A Situation- 
Goal-Behavior (SGB) model (ref. 42) of the 
VNAV function was constructed. This 
model identified all of the behaviors 
commanded by the VNAV function. This 
model also identified the MCP buttons and 
knobs used to invoke these behaviors, and 
the FMA associated with each behavior. 
This information was used in the cognitive 
engineering analysis. 

The Situation-Goal-Behavior (SGB) 
Model 

The behavior commanded by the VNAV 
function was modeled using the Situation- 
Goal-Behavior (SGB) model. The SGB 
model, a variation of the Operational 
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Table 2. The behavior of the VNAV function is defined by the legal combinations of 
functions/values for the VNAV outputs (left column). Each row defines the VNAV function 
output and it’s possible function/values. 


VNAV Outputs 

Possible Functions/Values 

Altitude target 

MCP window 

Climb Altitude Constraint 

Cruise Flightlevel 

Descent Altitude Constraint 

Conflict Altitude 

Destination Runway Elevation 

MDA 

Glide-slope Intercept Altitude 

Speed target 

Econ Climb CAS/Mach 
Edit Climb CAS/Mach 
Max Angle Climb 
Econ Cruise mach 
Edit Cruise CAS or Mach 
Max Endurance Cruise 
Econ Descent CAS/Mach 
Edit Descent CAS/Mach 
Max Descent 
Hold Speed 
Retum-to-Path Speed 
Decel Speed 
Approach Speeds 
Landing Speed (Vref) 

Vertical speed target 

MCP vertical speed window 
current vertical speed 
-750 fpm 

Speed || Altitude Control Modes 

THRUST || HOLD 
PITCH || CLB THRUST 
PITCH || IDLE 
THRUST || VS 


Procedure Model (ref. 42), layers a semantic 
goal model over a formal situation-action 
model of a finite state machine: 

• Situation =/ (state of environment 

from system inputs) (a) 

• Goal =/ (situation) (b) 

• Outputs=/ (goal, functions/values) 

(c) 

The behavior of a system under analysis is 
defined by the values of the outputs over 
time. The outputs are generated by a three- 
step process. The situation is determined by 
the conditions of the system inputs (equation 
a). The goal is determined by the situation 
(equation b). The output values are derived 
by executing a set of functions that are 


selected based on the active goal (equation 
c). The application of this model for 
cognitive engineering analysis of SGB 
models is described in Sherry et. al (ref. 43). 

SGB for VNAV 

The behavior of a modem VNAV function 
can be defined by the combinations of 
commanded functions/values assigned to 
each of the VNAV function outputs. These 
outputs and their possible functions/values 
are listed in Table 2. These outputs reflect 
the targets and modes that the pilot would 
select on the MCP if the VNAV function 
were not engaged. 
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Table 3. Summary of behavior of VNAV function. Behaviors are defined as unique combinations 
of altitude target, speed target, vertical speed target, and SPEED || ALTITUDE control modes 
computed by the FMS. 


VNAV GOAL 

VNAV COMMANDED BEHAVIOR 

SPEED || ALTITUDE Control 
Mode (FMA) 

CLIMB MAINTAIN CRZ FL 

Climb Maintain VNAV Alt 

PITCH ||CLB THRUST 

Maintain VNAV Alt 

THRUST || HOLD 

MAINTAIN CRZ FL 

Maintain CRZ FL 

THRUST || HOLD 

Climb Maintain Step CRZ FL 

PITCH || CLB THRUST 

Descend Maintain Step CRZ FL 

PITCH || IDLE THRUST 

DESCEND TO FAF 

Descend on FMS optimum path 

IDLE THRUST || PATH 
THRUST || PATH 

Descend Return to Optimum Path from 
Long (Late) 

PITCH || IDLE THRUST 

Descend Converge on Optimum Path 
from Short (Early) 

THRUST || VS 
PITCH || IDLE THRUST 

Maintain VNAV Alt 

THRUST/HOLD 

Descend Maintain VNAV Alt to Protect 
Speed 

PITCH || IDLE THRUST 

Descend Maintain VNAV Alt, Hold to 
Manual Termination 

THRUST || VS 


The SGB for the VNAV function is 
summarized in Table 3 (refs. 3, 44). Each 
unique VNAV commanded behavior 
represents a combination of values for 
altitude target, speed target, vertical speed 
target, and SPEED )| ALTITUDE control 
mode. The commanded behavior is selected 
to achieve a specific goal determined by the 
VNAV function. The SPEED || ALTITUDE 
FMA for each VNAV commanded behavior 
is also listed in Table 3. (Note: VNAV 
Approach behavior was not explicitly 
analyzed in this study. The conclusions from 
the analysis of the descent phase apply 
equally to the approach phase.) 


The commanded behaviors of the VNAV 
function are clustered into three VNAV 
function goals: 

CLIMB AND MAINTAIN THE 
CRUISE FLIGHTLEVEL (subject to 
altitude, and speed constraints and 
limits in the Flightplan) 

MAINTAIN THE CRUISE 
FLIGHTLEVEL (according to the 
profile of Cruise Flightlevels in the 
Flightplan) 

DESCEND TO THE 
FINALAPPROACH FIX (FAF) 
(subject to altitude and speed 
constraints and limits in the 
Flightplan). 
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When the VNAV button is selected the 
VNAV function commands trajectories to 
satisfy the altitude and speed 
constraints/limits in the FMS flightplan. 
During the climb phase of the flightplan, 
when the goal of the VNAV function is 
CLIMB AND MAINTAIN THE CRUISE 
FLIGHTLEVEL, the VNAV function 
commands two types of trajectories: (1) a 
climb (flight level change) trajectory at 
maximum climb thrust, or (2) a level flight 
(altitude hold) at the MCP altitude or 
flightplan altitude constraint. 

During the cruise phase of the flightplan, 
when the goal of the VNAV function is to 
MAINTAIN THE CRUISE 
FLIGHTLEVEL, the VNAV function 
commands a step climb, step descent, and 
altitude hold behavior as determined by the 
profile of Cruise Flightlevels in the 
flightplan. 

There are six behaviors commanded by the 
VNAV function during the descent and 
approach phases of the flightplan, when the 
goal of VNAV is to DESCEND TO THE 
FINAL APPROACH FIX (FAF): 

1 . Descend on FMS Optimum Path 

2. Descend Return to Optimum Path 
from Long (Late) 

3. Descend Converge on Optimum 
Path from Short (Early) 

4. Maintain VNAV Altitude (i.e. 
altitude constraints, MCP altitude, 
or other VNAV altitudes) 

5. Descend Open to VNAV Altitude to 
Protect Speed 

6. Descend to VNAV Altitude, Hold to 
Manual Termination 

The basic underlying concept of the VNAV 
function is that the VNAV function 
constructs and strives to fly an optimum 
path to the FAF. This path is a 


geographically-fixed pathway from the 
cruise flightlevel to the runway that is 
designed to optimize fuel bum and time, and 
takes into account the altitude crossing 
restrictions, and speed and time constraints 
(Figure 2). It is flown in much the same way 
as the aircraft flies a glideslope beam. 

To stabilize the aircraft at the FAF the 
VNAV function commands trajectories to 
capture and maintain the path. The 
appropriate trajectories are determined by 
decision-making rules embedded in the 
software that take into account the position 
and speed of the aircraft relative to the path 
and other parameters. The VNAV function 
will automatically transition between 
commanded behaviors based on the situation 
perceived by the automation based on sensor 
data. 

For example, when the aircraft is 
commanded to initiate the descent before the 
optimal FMS computed Top-of-Descent, the 
VNAV function automatically commands a 
VNAV Behavior to Descend and Converge 
on the Optimum Path, usually with a fixed 
rate-of-descent. The rate-of-descent is 
selected such that the aircraft converges on 
the optimum path (Figure 2). 

Alternatively, when the aircraft initiates the 
descent beyond the Top-of-Descent, the 
VNAV function automatically commands a 
VNAV Behavior to Descend and Return to 
Optimum Path. This VNAV behavior 
commands a descent at idle-thrust. Some 
VNAV functions increase the speed target to 
ensure convergence of the path (Figure 2). 
Frequently the VNAV function determines 
that additional drag is required to converge 
on the optimum path and requests extension 
of the air-brakes via an ND and MCDU 
message. 
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Maintain Descend Return 

Cruise to Optimum Path 

Flightlevei (from Short) Maintain VNAV 



Figure 2. Selecting the VNAV button invokes one of the VNAV commanded behaviors depending on 
the position of the aircraft relative to the FMS optimum path, the ATC clearance altitude, holding 
pattern at a fix, ...etc. 


The following two sections evaluate the 
VNAV button and the FMA used by the 
VNAV function against the cognitive 
engineering principles described above. 

VNAV: One Button - Multiple 
Automation Behavior 

The VNAV function violates the cognitive 
engineering design principle of one button - 
one automation behavior in the descent and 
approach phases of the flightplan. During 
these phases, the VNAV button invokes one 
of a set of possible behaviors (see Figure 3). 
Furthermore, the behavior commanded by 
the VNAV function will autonomously 
change as the situation evolves. 

When the VNAV button is selected during 
the climb and cruise phases of the flightplan, 
the VNAV function commands trajectories 
to climb, level, and descend according to the 
altitude and speed profile of the pilot entered 


flightplan. It is easy to determine and predict 
the behavior commanded by the VNAV 
function. There is only one pitch/thrust 
control strategy used to perform each of the 
climb, level, and descend trajectories. The 
VNAV goal and commanded trajectory can 
be easily distinguished by scanning the PFD 
altitude tape, FMA, ND, and thrust levels. 

Determining and predicting the trajectory 
commanded by the VNAV function is more 
complicated when the VNAV goal is to 
DESCEND TO THE FAF. When the VNAV 
button is selected during the descent and 
approach phase of the flightplan, the VNAV 
commanded trajectory is determined by the 
VNAV decision-making rules and can 
switch behaviors rapidly during a nominal 
descent depending on the situation. 
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In cognitive engineering terms, the VNAV 
button is overloaded in this phase of the 
flightplan. Like the climb and cruise phases 
of the flightplan, selecting the VNAV button 
commands the automation to follow the 
altitude and speed profile of the pilot- 
entered flightplan. Unlike the climb and 
cruise phases of the flightplan, during the 
descent phase, the VNAV function will 
command one of many different trajectories 
for descent, depending on the relative 
position of the aircraft to the FMS optimum 
path. The VNAV function will also 
command level-offs and decelerations in 
anticipation of downstream restrictions and 
constraints. 

In effect, the VNAV button engages a 
“meta-mode” (ref. 8) or “mega-mode” (ref. 
45). The notion of the VNAV button as a 
“meta-mode” is generally not understood by 
airline pilots (ref. 8). Several B757/767/747- 
400 pilots at a major U.S. airline pointed out 


that on the Boeing MCP the VNAV button 
is located adjacent to other single function 
buttons such as Altitude Hold and Flight 
Level Change. There is no visual indication 
that the VNAV button has meta- behavior. 

The overloading of the VNAV button is 
compounded by the autonomous decision- 
making of the VNAV function. Not only is 
it ambiguous which VNAV commanded 
behavior will be invoked when the VNAV 
button is selected, but the behavior 
commanded by the VNAV function will 
change as the situation perceived by the 
automation evolves (refs. 18, 29). A recent 
modification in the Airbus aircraft provides 
a triple-click aural warning when an 
infrequently occurring autonomous mode 
change occurs. 
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Push VNAV Button 

CLIMB MAINTAIN CRZ FL 

•CLIMB MAINTAIN VNAV ALT (FLCH) 

•INTERMEDIATE LEVEL AT VNAV ALT* (HOLD) 

MAINTAIN CRZ FL 

•MAINTAIN CRZ FL (HOLD) 

•STEP CLIMB TO CRZ FL (FLCH) 

DESCEND TOFAF 

•DESCEND ON PATH TO VNAV ALT (No Equiv. Autopilot Mode ) 
•DESCEND RETURN TO PATH (FROM LATE) (FLCH w/higher speed) 
•DESCEND CONVERGE ON PATH (FROM EARLY) (FLCH OR VS) 
•MAINTAIN VNAV ALT* (HOLD) 

•DESCEND HOLD TO MANUAL TERMINATION (VS) 


Input device 
Invokes MULTIPLE 
behaviors 


I — 

* VNAV ALT = 

MCP ALT or 

CROSSING RESTRICTION or 
MDA or 

VNAV LEVEL FOR 2 50/1 OK or 


Figure 3. All possible behaviors commanded by VNAV that result from selection of the 
VNAV button. The autopilot mode used for each VNAV behavior is included in 
parentheses. 
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VNAV: Many Automation Behaviors 
- One Display Configuration 

The VNAV function violates the cognitive 
engineering design principle of one 
display configuration - one automation 
behavior . More than one VNAV 
commanded trajectory will have the same 
display configuration of altitude targets, 
speed targets, vertical speed targets, and 
SPEED || ALTITUDE control modes. 
Table 2 illustrates how several different 
VNAV commanded trajectories share the 
same FMA. For example, the FMA PITCH 
|| IDLE THRUST is used for VNAV 
commanded behaviors to: 

1 . Descend and Maintain Step Cruise 
Flightlevel 

2. Descend and Return to Optimum 
Path from Long (Late) of the Path 

3. Descend and Converge on 
Optimum Path from Short (Early) of 
the Path 

4. Descend and Maintain VNAV Alt 
to Protect Speed. 

Another FMA that is overloaded is 
THRUST || VS. This FMA is used for two 
different commanded behaviors: (1) 
Descend Converge to the Optimum Path 
from Short (Early) and (2) Descend 
Maintain VNAV Alt while Hold to Manual 
Termination. 

This makes it difficult to determine with 
certainty the trajectory commanded by the 
VNAV function. To overcome this 
ambiguity, and to infer the VNAV 
commanded behavior, the pilot must scan 
the cockpit displays to determine aircraft 
situation relative to all of the constructs 
and thresholds used by the VNAV 
function decision-making logic. Using this 
information and the commanded targets 
and modes, the pilot uses memorized rules 
to infer the VNAV function goals and 
behavior. 


Several FMA designs in operation in 
modem aircraft compound this 
phenomenon further by introducing 
separate FMAs for the VNAV function 
even if the aircraft is using the same basic 
autopilot pitch/thrust control modes. Table 
4 summarizes the FMA for VNAV/PROF 
functions in descent on the A320 and 
B757. For example the B757 FMA for 
“climb maintain altitude” is FLCH || SPD 
when using the autopilot, and EPR || 
VNAV-SPD when using the VNAV 
function. The same flight level change 
behavior has two different FMAs. 

Not only is the pilot required to memorize 
a new set of FMA, but this additional set of 
FMA also hides the underlying philosophy 
of the VNAV function to capture and 
track the FMS optimum path. For 
example, the VNAV commanded behavior 
to Descend on the Optimum Path invokes 
a basic pitch control mode to track the 
FMS optimum path (the same way as the 
glideslope pitch mode tracks the ILS 
beam). The path control mode is not part 
of the basic autopilot control modes. The 
existence of this unique, VNAV-only, 
control mode, is not annunciated to the 
pilot. Not surprisingly, several pilots at 
major airlines describe the closed-loop 
pitch control for this VNAV behavior as 
“vertical speed mode” or “flight path 
angle mode.” Although these are good 
approximations, they are incorrect and can 
lead to misunderstandings of the 
automation behavior. One consequence of 
this misunderstanding is that flight crews 
may extend airbrakes when in the path 
control mode expecting an increase in the 
rate of descent, however the rate of descent 
will remain fixed while tracking the path. 
Extending airbrakes simple results in an 
increase in thrust to maintain the selected 
speed in the presence of the additional 
drag. 
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Table 4. A320 and B757 FMA and for VNAV commanded behaviors. Equivalent Autopilot 
thrust/pitch modes are in parentheses. 


VNAV Goal 

VNAV Behavior 

A320 FMA 

(Equivalent FG Mode) 

B757 FMA 

(Equivalent Autopilot Mode) 

CLIMB MAINTAIN CRZ FL 

Climb Maintain VNAV Alt 

THR CLB | CLB 
(THRCLB\OPCLB) 

EPR || VNAV-SPEED 
(FLCH\\SPD) 

Maintain VNAV Alt 

SPEED | ALT CST/ALTCST* 
(SPEED \ALT/ALr) 

SPD || VNAV-ALT 
(SPD || ALT HOLD) 

MAINTAIN CRZ FL 

Maintain CRZ FL 

MACH (ALT CRZ 
(MACH\ALT/ALr) 

SPD || VNAV-PATH 
(SPD \\ALT HOLD) 

Climb Maintain Step CRZ FL 

THR CRZ | CLB 
(THR CLB \ OP CLB) 

EPR || VNAV-SPEED 
(FLCH\\SPD) 

Descend Maintain Step CRZ 
FL 

DES 

(THRIDLE\OPDES) 

EPR || VNAV-SPEED 
(FLCH\\SPD) 

THR HOLD || VNAV-SPD 
(THR HOLD || SPD) 

DESCEND TO FAF 

Descend on FMS optimum 
path 

THR DES | DES 
(No Equiv. AP Mode) 

THR HOLD || VNAV-PATH 
(THR HOLD || No Equiv. AP Mode) 

SPD || VNAV-PATH 
(SPD || No Equiv. AP Mode) 

Descend Return to Optimum 
Path from Long (Late) 

THR DES|DES 
(THR IDLE \ OP DES) 

EPR || VNAV-SPEED 
(FLCHWSPD) 

THR HOLD || VNAV-SPD 
(THR HOLD W SPD) 

Descend Converge on 
Optimum Path from Short 
(Early) 

SPEED | DES 
(SPEED \FPA) 
(SPEED | VS) 

EPR || VNAV-SPEED 
(SPD || VSj 

THR HOLD || VNAV-SPD 
(SPD || VS) 

Maintain VNAV Alt 

SPEED | ALT CST/ALT CST* 
(SPEED \ALT/ALV) 

SPD || VNAV-ALT 
(SPD WALT HOLD) 

Descend Open and Maintain 
VNAV Alt to Protect Speed 

THR IDLE | DES 
(THR IDLE \ OP DES) 


Descend Maintain VNAV Alt, 
Hold to Manual Termination 

SPEED | DES 
(SPEED \V/S) 

SPD || VNAV-SPD 
(SPD || VS) 
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Design Improvements 

Overloading the input devices and 
FMA/Display configuration for the VNAV 
function violates two basic cognitive 
engineering design principles. These are 
known causes of operator confusion and 
can, in part, contribute to the increased 
workload of the VNAV function in descent 
and approach. Boeing, Honeywell, NASA 
and airlines are working to address this issue 
along with other issues of ATC/FMS 
compatibility and vertical situation 
awareness. Several proposed design 
improvements for the VNAV user-interface, 
based on the cognitive engineering 
principles, are described below. 

Separate input device to use FMS 
flightplan targets from input device to 
capture and tracks the FMS optimum 
path 

As described above, the VNAV button 
selects the FMS flightplan as the source of 
altitude, speed, and vertical speed targets, as 
well as the pitch/thrust control mode. The 
behavior of the VNAV function during the 
climb and cruise phases of the flightplan is 
intuitive since there is only one trajectory 
that can be commanded for each segment. 
VNAV function behavior is not intuitive in 
the descent and approach phases of the 
flightplan. During these phases the VNAV 
function determines the targets and modes to 
satisfy the flightplan. It also uses decision- 
making logic to autonomously command a 
series of trajectories to capture and track the 
path. 

The design improvement proposed is to 
decouple the selection of the source of 
altitude and speed targets, from the selection 
of the control modes. Figure 4 illustrates an 
example MCP that includes input devices 
(knobs) for selecting the source of the 
targets. A separate input device (the DES 
PATH button) is provided to arm the capture 
and tracking of the path. If the input device 
is selected when the aircraft is not within the 


capture region to the path, the “path” mode 
is armed, and the pilot uses traditional flight 
level change and vertical speed modes to 
converge on the path. When the aircraft 
achieves the capture region, the “path” mode 
is automatically engaged. This behavior 
mimics the capture and tracking of the 
glideslope. 

Dynamic Label on the VNAV Button 

An alternative to decoupling the flightplan 
targets from the control modes, described 
above, is to maintain the existing user- 
interface with the VNAV button, but add a 
dynamic label that annunciates what it will 
do when it is selected. Sherry, et. al., (ref. 

39) proposed using an LCD display on the 
MCP to annunciate the VNAV commanded 
trajectoiy that would be engaged when the 
button is selected. 

This proposal allows different behaviors to 
be invoked from the same button depending 
on the situation. These different behaviors 
are explicitly annunciated. The downstream 
autonomous changes made by the 
automation would also be displayed in this 
display in the dynamic label. 

Unique FMA for VNAV function 

The FMA for the VNAV function should be 
unique for each VNAV commanded 
trajectory. 

Annunciation of Autopilot Control Modes 

One FMA design paradigm is to use the 
existing autopilot pitch/thrust control modes 
to build on the pilots existing mental model. 
This eliminates the need to learn two sets of 
FMA, one for the Autopilot and one for 
VNAV. This design will also explicitly 
annunciate VNAV specific control modes, 
such as the path control modes, that are not 
traditional Autopilot modes. 
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Figure 4. Example of MCP designed according to the cognitive engineering principles. This MCP 
explicitly provides input devices to command to the FMS flightplan lateral path, altitude and speeds 
(push knobs). A separate input device (DES PATH button) provides the option to arm the capture 
and tracking of the FMS optimum path. This button has only one behavior - to capture and track the 
path. 


Annunciation ofVNAV Goals/Behavior 

An alternative FMA design paradigm is to 
annunciate the VNAV commanded behavior 
as described in the SGB model in Table 1 
(refs. 3, 46). Feary et. al (ref. 27) 
demonstrated improved pilot performance 
(p<0.03) during VNAV operation with the 
display of the VNAV commanded behavior 
(instead of the control modes). 

Conclusions 

This paper describes how the VNAV button 
on the MCP is overloaded. Selecting the 
button in the descent phase can command 
one of six possible behaviors. Furthermore, 
due to the decision-making logic of the 
VNAV function the commanded behavior 
will autonomously change as the situation 
perceived by the VNAV function changes. 

The FMA used by the VNAV function is 
also overloaded. A given FMA represents 
more than one VNAV commanded behavior. 
These two types of overloading are well 
known sources of operator confusion and 
make it very difficult for a pilot to learn the 


behavior of the VNAV function simply 
through observation. 

In addition to making the function more 
compatible with ATC operations, Boeing, 
Honeywell, NASA, and airline partners are 
investigating changes to the user-interface to 
eliminate the overloading of the VNAV 
button and the overloading of the FMA used 
by the VNAV function. As with most 
complex design decisions, there are several 
trade-offs that must take place. 

Trade-offs for Input Device Redesign 

The proposal to decouple the selection of 
source of altitude and speed targets from the 
flightplan or MCP, from the selection for 
arming the FMS optimum path control mode 
creates a more operationally meaningful 
user-interface at the expense of adding 
another input device. The advantage is to 
unambiguously declare the existence of the 
path and the path control mode. 

The decoupling of the control to the 
flightplan targets from the automatic arming 
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of the capture and track of the path is very 
much the spirit of the concepts of 
“Managed” and “Selected” modes used on 
the Airbus. In the managed mode the Flight 
Management/Flight Guidance (FM/FG) 
system follows the flightplan. In the selected 
mode the FM/FG follows pilot entries in the 
Flight Control Unit (FCU) (the Airbus term 
for MCP). 

The input device to capture and track the 
path invokes one VNAV trajectory, as 
would other buttons on the display. This 
path mode has the same type of functionality 
provided by the glideslope of the Instrument 
Landing System (ILS) and will enable pilots 
to transfer their knowledge of the behavior 
of the ILS (available on “steam gauge” 
aircraft) to the behavior of the VNAV 
function. This operation will also match the 
operation of the LNAV button that arms the 
capture and tracking of the lateral path. 

Eliminating the “off path” decision-making 
logic in the FMS reduces a significant 
amount of complex software from the FMS. 
This will translate to improved software 
integrity and possibly a reduction in the 
costs of development and testing. 

The trade-off made to achieve this 
simplification of the input device is that the 
VNAV function will now arm for a capture 
of the optimum path when it is not within 
the capture region to the path. The pilot is 
now more directly involved in determining 
the commanded trajectory and is responsible 
for ensuring convergence on the path with 
the aid of the FMS computed intercept 
displayed on the ND. The pilot is also 
responsible for monitoring the autonomous 
transition from the armed state to the 
capture. One of the changes required would 
be to add the display of the armed mode on 
the FMA. Several Airbus and Boeing 
aircraft currently display armed modes, and 
more specifically annunciate the armed 
capture of the path. In addition, the 
automatic transition from armed state to 


engaged state should be brought to the 
pilots’ attention by flashing FMA and by 
aural indications such as the Airbus triple- 
click. 

Trade-offs for Annunciation Redesign 

The proposal outlined above to create an 
input device to choose the flightplan as the 
source of altitude and speed targets (as 
opposed to the pilot selected MCP targets) 
requires an annunciation in the cockpit to 
distinguish between the two sources. This 
could be accomplished by a VNAV prefix 
on the FMA such as on Boeing aircraft, or 
magenta color of PFD altitude and speed 
targets as on the MD-1 1. 

There should also be unique annunciation 
when the path control mode is armed, 
captures, and tracks the path. Boeing 7XX 
series aircraft already annunciate VNAV- 
PATH for this mode. Likewise the MD-1 1 
already annunciates PROF. Also there are 
several precedents for annunciation for the 
ILS modes. 

Aircraft in the field 

For aircraft already in the field, resolving 
the overloading can only be achieved by 
training - building knowledge-in the heads 
of the pilots - on the behavior of the VNAV 
function input devices and displays. Using 
modem pedagogical principles (refs. 32, 47) 
pilots are provided basic concepts 
underlying the behavior of the automation 
(refs. 48, 49). These concepts are used to 
learn declarative rules of the detailed 
behavior of the automation (refs. 4, 39, 41). 
The declarative rules are then compiled into 
procedural knowledge through drill-and- 
practice on cognitive tutors (refs. 32, 50). 

Automation design philosophy 

The defacto philosophy of developing 
cockpit automation to automate operator 
tasks is counter to the cognitive engineering 
design principles that emphasize the need 
for pilot involvement and unambiguous 
feedback. Automation in the cockpit has 
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been most successful in performing 
repetitive tasks of real-time control (e.g. 
closed-loop control of pitch axis), 
optimization computations (e.g. ECON 
speed, V-speeds), and editors and database 
(e.g. flightplan “editor” using 


the MCDU, ND, and the worldwide 
Navigation Database). These functions 
genuinely make the pilot smarter and reduce 
pilot workload. 

Functions that automate operator tasks that 
are associated with the execution of the 
mission tend to have a high requirement for 
situational awareness and mission 
knowledge. These functions are more like 
smart expert systems and require high levels 
of communication and interaction that may 
exceed the capabilities of the technologies of 
“glass cockpit” user-interfaces as we know 
of them. 
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